DR-001-Arch: Consistent Stack vs. Reference Integration#2560
DR-001-Arch: Consistent Stack vs. Reference Integration#2560
Conversation
qor-lb
requested review from
PandaeDo,
aschemmel-tech,
masc2023 and
pahmann
as code owners
|
|
|
The created documentation from the pull request is available at: docu-html |
qor-lb
requested review from
FScholPer,
antonkri and
johannes-esr
as code owners
|
Seems related to #2346, Feature as stand-alone Delivery? |
Yes agree, added it to the list in the description above. |
FScholPer
left a comment
FScholPer
left a comment
There was a problem hiding this comment.
What option is accepted or did I miss something?
aschemmel-tech
left a comment
aschemmel-tech
left a comment
There was a problem hiding this comment.
see inline comment
FScholPer
left a comment
FScholPer
left a comment
There was a problem hiding this comment.
no accepted option defined
@FScholPer the decision is right after the context: https://github.com/eclipse-score/score/pull/2560/changes#diff-7605e72a4577a9aeeadf15aca38407709dc0eff885ee5684e8d46097ef932da8R44 |
There was a problem hiding this comment.
Original (blocking) remark is covered. As I understood the discussion in "Alignment Tech Leads, Community Leads & Feature Team Leads" meeting, there needs to be some description how we want to deal with "breaking API changes", which would also differentiate between "small" and "big" changes. Maybe a possibility to differentiate is to ask: "is this change affecting the logical interface described in our Feature Architecture?" - because if yes, the process is asking for a "Feature Change Request" which would also result in planning activities.
|
|
||
| In particular, the consistent stack approach does not prevent modules or features from being independently buildable or releasable, nor from being used outside the S-CORE stack. | ||
|
|
||
| The decision only establishes that, when modules are integrated into S-CORE, their evolution and changes must be justified in terms of stack-level objectives. |
There was a problem hiding this comment.
Imho the heart of the question is about responsibility for breaking changes and that goes beyond "changes must be justified in terms of stack-level objectives".
Let's assume module X makes a breaking change from version 42 to 43 and an S-CORE release is imminent. Now I see two options how integration can be handled and they somewhat correspond to the considered options 1 and 2:
Option 1: Module X does not integrate, thus we cannot release S-CORE yet. Integrators organize to get the version 43 improvements in.
Option 2: Module X does not integrate, thus we release S-CORE with old version 42. Module X if you want to be in the release, you need to work.
There was a problem hiding this comment.
@a-zw from my perspective both options would still be valid even under the current proposed decision. I have added a subsection to the Impact on Governance and Planning section to try and clarify that. Let me know it this resolves your comment or if you feel differently.
7 participants
Formal decision record based on discussion during last architecture community workshop: https://github.com/orgs/eclipse-score/discussions/1922#discussioncomment-14871055
This intends to establish a discussion basis for further technical dr's such as:
Important
This PR will be kept open at least until 13th Feb before merging to ensure that necessary reviews can be conducted.